Rulesを利用して、id_tokenのクレームにuser_metadataを追加する

はじめに

Auth0のRules記事第二弾(個人)です。

今回は、Rulesでid_tokenのクレームにuser_metadataを追加する機能を試してみました。そもそもRulesでどのような情報が取れるのか知りたい方は、過去記事を読んでみてください。

Auth0のRulesで使えるオブジェクトを出力してみた！

名前空間について

id_tokenには名前空間が存在し、任意のクレームを追加する上でルールが存在します。 詳細は、Auth0ドキュメントのUser profile claims and scopeに記載されておりますが、簡単に要約、翻訳すると以下の通りです。

名前空間のルール

Auth0は「OIDC仕様でカスタムクレーム識別子は衝突耐性があることを推奨している」ことを受けて、以下のような仕様になっています

• HTTP/HTTPSのURLを名前空間識別子として、任意の数の使用可能 (※1)
• 名前空間のURLはあくまで識別子、Auth0によって呼び出されることはない (※2)
• HTTP/HTTPS名前空間のないカスタムクレームは、トークンから除外される

※1 auth0.com、webtask.io、webtask.runはAuth0ドメインであるため、名前空間識別子として使用不可
※2 実際のリソースである必要もない

id_tokenにuser_metadataを追加してみる

構成

• クライアントアプリ
  Auth0のSINGLE PAGE APPLICATIONのAngularサンプルを利用

• クライアントアプリに渡されたid_tokenの確認方法
  Chrome Developer ToolsのNetworkタブで、流れてきたid_tokenをデコード

user_metadataを設定する

Rulesコードを書く

function (user, context, callback) {
  const namespace = 'https://myapp.example.com/';
  console.log(`user_metadata is ${user.user_metadata}`);
  console.log(`context.idToken before : ${JSON.stringify(context.idToken)}`);

  context.idToken[`${namespace}user_metadata`] = user.user_metadata;

  console.log(`context.idToken after : ${JSON.stringify(context.idToken)}`);

  callback(null, user, context);
}

結果

Rulesなしの場合のid_tokenのPayloadデコード結果

{
  "nickname": "xxxxxx",
  "name": "[email protected]",
  "picture": "https://s...",
  "updated_at": "2019-08-25T08:21:36.910Z",
  "email": "[email protected]",
  "email_verified": true,
  "iss": "https://{テナントのドメイン}.auth0.com/",
  "sub": "auth0|5...",
  "aud": "Cf...",
  "iat": 1566721299,
  "exp": 1566757299,
  "nonce": "gS4..."
}

Rulesありの場合のid_tokenのPayloadデコード結果

{
  "https://myapp.example.com/user_metadata": { // <-- 追加されている
    "foo": "bar"
  },
  "nickname": "xxxxxx",
  "name": "[email protected]",
  "picture": "https://s...",
  "updated_at": "2019-08-25T09:21:08.414Z",
  "email": "[email protected]",
  "email_verified": true,
  "iss": "https://{テナントのドメイン}.auth0.com/",
  "sub": "auth0|5...",
  "aud": "Cf...",
  "iat": 1566724870,
  "exp": 1566760870,
  "nonce": "Lt..."
}

最後に

本記事の手法を活用することで、Rules内でサードパーティ製APIや既存の社内システムのAPIを実行しid_tokenに含めることも勿論可能です。 クライアントアプリが知っておくべき情報を、極力Rules経由でid_tokenで渡すことにより、クライアント側で無駄な通信をしなくてよくなるため、活用していきたいところです。